Skip to content

pkg/sbx: Add docker-sbx packaging support#392

Open
vvoland wants to merge 4 commits intodocker:mainfrom
vvoland:sandboxes
Open

pkg/sbx: Add docker-sbx packaging support#392
vvoland wants to merge 4 commits intodocker:mainfrom
vvoland:sandboxes

Conversation

@vvoland
Copy link
Copy Markdown
Collaborator

@vvoland vvoland commented Mar 30, 2026

Add deb, rpm, and static packaging for the sbx. Includes build scripts, AppArmor profile for the nerdbox shim, verification Dockerfile, and runtime binary fetch script.

@vvoland vvoland self-assigned this Mar 30, 2026
@vvoland vvoland requested a review from a team as a code owner March 30, 2026 15:04
@vvoland
Copy link
Copy Markdown
Collaborator Author

vvoland commented Mar 30, 2026

cagent failures unrelated

@vvoland vvoland force-pushed the sandboxes branch 2 times, most recently from 52828e1 to a88dbe7 Compare March 30, 2026 15:48
Comment on lines +37 to +40
install -D -p -m 0755 /usr/local/libexec/mkfs.erofs ${RPM_BUILD_ROOT}%{_libexecdir}/mkfs.erofs
install -D -p -m 0755 /usr/local/libexec/mkfs.ext4 ${RPM_BUILD_ROOT}%{_libexecdir}/mkfs.ext4
install -D -p -m 0644 /usr/local/libexec/%{_kernel_artifact} ${RPM_BUILD_ROOT}%{_libexecdir}/%{_kernel_artifact}
install -D -p -m 0644 /usr/local/libexec/%{_initrd_artifact} ${RPM_BUILD_ROOT}%{_libexecdir}/%{_initrd_artifact}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any licensing checks needed for these? (i.e., can they be included in Apache 2)?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually; shouldn't we just define a dependency for these? Any reason we're packing it ourselves?

dnf provides -q */mkfs.ext4
e2fsprogs-1.47.3-2.fc43.aarch64 : Utilities for managing ext2, ext3, and ext4 file systems
Repo         : fedora
Matched From :
Provide      : e2fsprogs = 1.47.3-2.fc43


dnf provides -q */mkfs.erofs
erofs-utils-1.9.1-1.fc43.aarch64 : Utilities for working with EROFS
Repo         : updates
Matched From :
Filename     : /usr/bin/mkfs.erofs

erofs-utils-1.8.10-2.fc43.aarch64 : Utilities for working with EROFS
Repo         : fedora
Matched From :
Filename     : /usr/bin/mkfs.erofs

Copy link
Copy Markdown
Collaborator Author

@vvoland vvoland Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sbx package is proprietary, not Apache 2.
Good catch though, we need to include a notice about the usage of binaries built off GPL source.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the ext4 we could use system package, but I want to keep it aligned with non-Linux versions.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For erofs it's a bit more complicated, as it's not available by defaut in RockyLinux9 (which is needed).

@vvoland vvoland force-pushed the sandboxes branch 5 times, most recently from eb8664c to 7696a40 Compare March 30, 2026 17:40
@vvoland vvoland requested a review from thaJeztah March 30, 2026 17:52
%doc %{_docdir}/docker-sbx/THIRD-PARTY-NOTICES
%license LICENSE
%license GPL-2.0
%license Apache-2.0
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this the correct way to handle the licenses (or would this be considered dual/triple licensed?)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this only adds these files (containing license texts) to licenses.

The actuall license spec is:

License: Proprietary AND GPL-2.0-only AND GPL-2.0-or-later AND Apache-2.0

See:

https://docs.fedoraproject.org/en-US/legal/spdx/#_and_expressions

AND Expressions

A compound SPDX expression may be formed by joining two SPDX expressions with the AND operator. This generally signifies that both sub-expressions apply to different parts of a file or package. Example: LGPL-2.1-or-later AND GPL-2.0-or-later AND MIT

Copy link
Copy Markdown
Member

@crazy-max crazy-max left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a serious supply-chain objection to this packaging approach. This doesn't build the full shipped payload from source in a single auditable pipeline.

RUNTIME_SRC is defined as an external directory of pre-built runtime binaries, pkg/sbx/scripts/fetch-runtime-binaries.sh populates that directory by downloading release artifacts with gh release download, and the packaging scripts then copy those blobs directly into the deb/rpm/static outputs.

That means we are shipping a package that includes security-sensitive runtime components without producing them from source.

That's not a small detail imo. The provenance and SBOM generated by this repo can only attest to the repackaging step. They don't attest to how those binaries were actually built, from which exact source commit, with which toolchain, with which patches, or whether they are reproducible from source or work on target distributions at all.

As discussed offline with sandboxes team I think we could set up a GitHub App to fetch sources from the private repo.

# https://github.com/docker/cagent/blob/1a83a28df2b0769e8cb14d54ac409bdbb98e254c/Taskfile.yml#L66
cagent = ["darwin/amd64", "linux/arm/v7", "darwin/arm64", "linux/amd64", "linux/arm64", "windows/amd64", "windows/arm64"]
# https://github.com/docker/sandboxes/blob/main/docker-bake.hcl
sbx = ["linux/amd64"]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does not build on arm64?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed for now.

}
}

target "_pkg-sbx" {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's on purpose as these won't be ran from CI in this repo.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum then why adding this package here in the first place?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To not reinvent the wheel and reuse the structure we have here.
The sbx CI will just clone this repo and run the bake definitions from here.

Copy link
Copy Markdown
Member

@crazy-max crazy-max Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sbx CI will just clone this repo and run the bake definitions from here.

In this case we don't need anything here, they can just have deb/rpm specs on their side and have an override bake definition docker-bake.override.hcl that would just define bake targets added here (mainly _pkg-sbx). Bake will lookup automatically for this override and merge with main one when running the build.

They can then build remotely docker packaging using remote bake def and override with their local one: https://docs.docker.com/build/bake/remote-definition/#combine-local-and-remote-bake-definitions

Copy link
Copy Markdown
Collaborator Author

@vvoland vvoland Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, interesting. How to extend (instead of replacing completely) the PKGS variable and pkgPlatforms function in the override?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, interesting. How to extend (instead of replacing completely) the PKGS variable and pkgPlatforms function in the override?

Good point I will check this. We might need changes in the bake definition.

# https://github.com/docker/cagent/blob/1a83a28df2b0769e8cb14d54ac409bdbb98e254c/Taskfile.yml#L66
cagent = ["darwin/amd64", "linux/arm/v7", "darwin/arm64", "linux/amd64", "linux/arm64", "windows/amd64", "windows/arm64"]
# https://github.com/docker/sandboxes/blob/main/docker-bake.hcl
sbx = ["linux/amd64"]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No support for arm64?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed for now.

vvoland added 2 commits March 30, 2026 22:33
Add deb, rpm, and static packaging for the sbx.

Includes build scripts, AppArmor profile for the nerdbox shim,
verification Dockerfile, and runtime binary fetch script.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Add a `build-erofs` Dockerfile stage that clones erofs-utils at a
pinned tag (v1.9.1) and compiles mkfs.erofs with lz4, lzma, and zstd
support. The built binary is mounted into the deb, rpm, and static
packaging stages via /opt/erofs-bin.

This replaces the previous approach of downloading a pre-built
mkfs.erofs binary from GitHub releases. The fetch-runtime-binaries.sh
script no longer downloads the mkfs.erofs binary.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
vvoland added 2 commits March 30, 2026 23:55
Add ca-certificates to Depends (deb) and Requires (rpm) so that
TLS certificate verification works out of the box.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The upstream sandboxes Dockerfile needs either SSH forwarding or a
GITHUB_TOKEN secret to fetch private Go modules. Without these, the
build fails with "cat: can't open '/run/secrets/GITHUB_TOKEN'".

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants